Cluster Autoscaler

#cloud #architecture #cloud-native #kubernetes/addon/cluster-autoscaler #autoscale #automation #scaling #node

개요

레포의 상태가..

image.png
재밌게도, 여러 툴들을 한 레포에서 autoscaler라는 묶음으로 관리하고 있다.
각각이 하는 역할이 다르기에 나는 이를 구분해서 문서로 작성하고자 한다.

클러스터의 노드가 부족할 때 자동으로 늘리는 툴.
파드를 늘리는 HPA, Vertical Pod Autoscaler과는 다르게 노드를 늘려서 추가 자원을 확보한다.
이를 통해 인프라를 프로비저닝하는 환경에 대한 각종 커스텀이 필요하다.
요즘에는 Karpenter를 사용할 수 없는 환경에서만 쓰이는 것 같다.

원리

기본적으로 클러스터 오토스케일러는 현재 클러스터의 상태를 감시한다.

그러면 이후에 노드를 추가하거나 삭제를 해주는 것은 전적으로 외부 제공자의 책임이 된다.
가령 AWS에서는 오토스케일링그룹을 통해 노드가 추가, 삭제된다.

기능

클러스터 스케일 업

자원 부족으로 인해 파드가 스케줄에 실패했을 때 클러스터 오토스케일러가 동작한다.
즉, 스케줄링이 실패했을 때만 발동한다는 것이다.
이것은 cpu의 사용량을 기반으로 스케일링을 하는 다른 노드 스케일러 솔루션과 차별되는 점이다.

구체적으로는 다음의 과정을 따른다.

이 스케일러는 노드를 만들고 노드 오브젝트를 등록하는 작업에 책임을 지지 않는다.
그저 --max-node-provision-time(기본 15분)내에 클라우드 제공자가 적절하게 노드를 붙여주기를 바랄 뿐이다.
이 시간 내에 노드가 등록되지 않으면 노드가 등록되지 않았다고 간주하고 새로 노드를 증설해달라 찡찡댄다.

클러스터 스케일 다운

자원이 지나치게 남아돌면서 중요도가 적은 파드들이 위치한 노드가 있을 때도 노드를 줄이는 방향으로 동작한다.

이때 어떤 파드가 있는 노드들이 살아남을 수 있을까?

이런 파드들이 위치한 노드라면 해당 노드는 지워지지 않을 것이다.

왜 emptyDir도 고려되는가?

emptyDir은 파드 내에서만 쓰이는 건데 이걸 로컬 종속성이 있다는 이유로 제외하는 게 맞나?
어차피 휘발될 거 감안하고 쓰는 스토리지인데..

아예 특정 노드를 사라지지 않게 하고 싶다면 노드에 "cluster-autoscaler.kubernetes.io/scale-down-disabled": "true" 어노테이션을 걸어준다.

스케일 다운은 아래의 과정을 따른다.

오버프로비저닝

리소스가 많이 필요할 것이 예상되는 시점에 미리 스케일 업을 해두고 싶다면 이런 식의 꼼수를 부릴 수 있다.
일단 임의의 파드를 늘린다.
다만 이 파드의 우선순위를 극한으로 낮춰서 다른 필요한 파드가 배치돼야할 때 언제든지 축출될 수 있도록 한다.

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: overprovisioning
value: -10
globalDefault: false
description: "Priority class used by overprovisioning."
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: overprovisioning
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      run: overprovisioning
  template:
    metadata:
      labels:
        run: overprovisioning
    spec:
      priorityClassName: overprovisioning
      terminationGracePeriodSeconds: 0
      containers:
      - name: reserve-resources
        image: registry.k8s.io/pause:3.9
        resources:
          requests:
            cpu: "200m"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: overprovisioning-autoscaler
  namespace: default
  labels:
    app: overprovisioning-autoscaler
spec:
  selector:
    matchLabels:
      app: overprovisioning-autoscaler
  replicas: 1
  template:
    metadata:
      labels:
        app: overprovisioning-autoscaler
    spec:
      containers:
        - image: registry.k8s.io/cluster-proportional-autoscaler-amd64:1.8.1
          name: autoscaler
          command:
            - /cluster-proportional-autoscaler
            - --namespace=default
            - --configmap=overprovisioning-autoscaler
            - --default-params={"linear":{"coresPerReplica":1}}
            - --target=deployment/overprovisioning
            - --logtostderr=true
            - --v=2
      serviceAccountName: cluster-proportional-autoscaler-service-account

단점

이 친구는 실상 Karpenter를 쓸 수 없는 환경에서 사용하는 차안 같은 느낌이다.
왜냐하면 아래의 문제점들이 있기 때문이다.

관련 문서

이름 noteType created
Cluster Autoscaler knowledge 2025-03-05

참고